home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 9 / AMUG BBS in a Box Volume IX (August 1993) (MacWizards).iso / Files / Prog / B-C / C++Source Code Fmtr.cpt / Defect List / Defect List
Encoding:
Text File  |  1991-04-29  |  3.1 KB  |  74 lines  |  [TEXT/MPS ]
  1.     • Bug: "int a,// comment \n b;" has the "b" flush left.
  2.     • Bug: "int a[] = {1,2,3,4};" has the "1,2,3,4};" on a newline
  3.     • Bug: "x = !x;" is displayed as "x =! x;".  Problem in "!"
  4.     • Add comment glue for Sussna
  5.     • Add glue for #lines.  Check if needline(2) is required.
  6.     • Add commands in comments
  7.  
  8.  
  9.  
  10.     • Bug: "if (xxx)){" --> "if (xxx){"
  11.     √ Ignored: 04/29/91
  12.  
  13. This situation is syntactically invalid.  It arises when the Pascal to C
  14. conversion script is run.  Although it munches tokens instead of yielding
  15. an error, it will remain as it is more useful than harmful.
  16.  
  17.  
  18.  
  19.     • Bug: "void (Target::*aMethod)(int)" --> "void(Target ::*aMethod)(int)"
  20.     √ Fixed: 04/29/91
  21.  
  22. The "::*" case is now handled by the PrsId class, which already handles the
  23. "::" case.
  24.  
  25.  
  26.  
  27.     • Bug: "Rect a,  b;" has extra blank after the ","
  28.     √ Fixed: 04/25/91
  29.  
  30. The declaration had to be in the body of a function.  The bug was caused
  31. by an interaction between the parser and the formatter.  The parse would
  32. enter a declaration parse state after the ", " was displayed by doing an 
  33. Accept(&gLexDecl).  The parser would sing and dance while consuming this
  34. parse-effect-only token.  Part of the song and dance was to call
  35. Formatting::Display() on this magic cookie.  Nothing would be displayed,
  36. but the formatter would remember that it had just been asked to display
  37. something with identifier nature.  When the "b" came along, the glue had
  38. a conditional: if the previous thing was a an id, then emit a
  39. space ("?i{s}{}").  So, one space came from the glue for "," and the other
  40. from the glue for names.
  41.  
  42. The fix (the second one, far cleaner than the first), was to have the
  43. Syntactic::Display() abstract method return a Boolean.  The method returns
  44. true if something was displayed, false if nothing was displayed.  Then
  45. Formatting::Display() would update its information about what was last
  46. displayed only if anything was displayed.
  47.  
  48.  
  49.  
  50.     • Bug: "ObjectTable::IObjectTable(very long declaration list which rescans…)"
  51.     √ Fixed: 04/25/91
  52.  
  53. The bug occurred when the line length overflowed and rescanning was invoked.
  54. The output would have "ObjectTableIObjectTableObjectTable::IObjectTable" as
  55. the name of the method.  The reason was because "ObjectTable::IObjectTable"
  56. was saved twice.  It was saved once as a synthesized kSPrs_Id, which would
  57. be redisplayed, and each of its components would be saved.  When rerun, the
  58. two would be re-emitted with the bogus results appearing.
  59.  
  60. The fix was part of the previous fix:  when Formatting::Display() calls a
  61. Syntactic::Display() method, the token is saved for replay only if the
  62. token was actually displayed.  Otherwise, it is ignored.  The synthesized
  63. kSPrs_Id always displays its component objects, which are saved in the
  64. replay buffer, but then returns false, causing the synthesized object to
  65. not be remembered.  This leaves the desired effect.
  66.  
  67. A potential problem is if a false-returning synthesized object's Display()
  68. method does something other than specify glue or call its component's
  69. Display() methods: those other operations will not be replayed.  The
  70. current set of synthesized objects does not suffer from this problem.
  71.  
  72.  
  73.  
  74.